Thorsten Froehlich wrote:

> Why?  The policy to not make development source code accessible has a good
> reason, because it simply did not work in the past.  Considering that back
> in that "past" far fewer users with a lot more technical clue has access
> to online resources, the internet of today does only make matters worse.
> 
The proper reaction IMO is to find those people which do have a clue. 

> But you have access to the source code.  Use it.  Honestly I have to say
> several of the contributed bug fixes we so far got for 3.5 cannot (well,
> should not) be used as is in the source code.  While many bug fixes
> correctly identify the problem, they frequently tend to be more of a
> "hack" than a solution.
> 
I cannot comment on that beause I did not see them. 
(And as other peple out here do not see them, they can hardly come up 
with something better.)

> And periodically looking at various "open source" development projects
> makes
> me worry a lot about even considering using that software.  Despite its
> age, the POV-Ray source code is in a very good shape compared to many much
> younger "open source" projects whose individual modules are rewritten
> every three or four years...
>
[I am skipping this paragraph in an attempt to not feed the trolls.]
 
> My personal opinion is that no future patches' source code from MegaPOV
> should be added to an official POV-Ray at all.  This is from the very bad
> experience with patch quality that caused massive problems getting a
> timely release of POV-Ray 3.5, and even in 3.6 not all of the flaws in
> some patches have been corrected.
> 
I do not completely understand that. In order to advanve/innovate one 
needs to add code to existing code, hence "patch" it. If you do not 
patch code, you stop development. 

So what is the alternative?
Direct implementation by a POV team member (with inspiration from 
the patch code)? 

In this case we definitely need megapov as a patch playground because 
the above tends to take quite long...

Maybe we are using slightly differrent meanings for "patch". 

> Apart from that, with 4.0 being a rewrite, producing patches, especially
> some that just add minor individual tweaks (usually by parser or
> preprocessing data later rendered) rather than new objects, are of very
> little use because those parts of POV-Ray are in a major need for a
> rewrite while most of the objects can just be converted.
> 
This is clear (although I think that "just converting" the parametric 
object will not be that easy...)

As you are talking about version 4.0, I think it should not only be 
a re-write but a re-design in that it allows several things being 
done which one would like to do with the current version but cannot 
due to design resaons. 
But probably design is already being discussed in the group?

>> To me (as looking at it from outside) it seems like there would be
>> enough ideas, code and manpower around here for quite some innovation
>> but there is somebody somewhere out there actively pulling the break.
> 
> Well, POV-Ray is a program for users, not for developers.  
>
Correct. And my terms of "use" of software imply that I change that 
software in case it does not fit my use. 

> Just adding
> features is the absolute wrong way of doing development.  If you want to
> contribute, there is a long list of outstanding bugs on www.povray.org and
> p.bugreports that definitely have a higher priority than adding new
> features.  
>
These lists do by no means contain all issues which should be improved. 

My mode of contribution is to write something which is immediately 
useful for _me_and_ the other users. 

It is unlikely that I start writing a fix for the "fog+media" problem 
because I do not use fog. So this problem is simply irrelevant for me 
(at least currently). 

> And you can be sure the community as well as the POV-Team will
> greatly appreciate bug fix contributions.
> 
(And any bug fix writer will appeciate access to up-to-date source code...)

> Still, also said list has been available since the release of POV-Ray 3.5,
> I am only aware of two people only ever to look into any of them.
> 
Then I am probably the third one :)

I did not look at the 
"Known bugs in POV-Ray version 3.5 that will be fixed in soon"
because it already says that obviously the solution already exists. 

The "Known bugs in POV-Ray version 3.5" either seem unimportant to 
me (superflouos warnings) or I have no clue about them (radiosity). 

About the "Bugs inherited from POV-Ray 3.1 and older versions", 
I read them, then thought that some more clever people failed to correct 
them and that I would try to fix and of them in case I actually 
hit one myself. As for the bugs in the parser, I'd suggest a complete 
rewrite anyways. 

>> I learned that in most cases it turns out negatively to hinder those
>> people who want to work (and have the ability to do it well) from
>> doing their work.
> 
> I strongly disagree.  All "those people who want to work" usually do only
> want to add features.  They have no desire to go through the very time
> consuming, boring and frequently frustrating process of fixing bugs.  So,
> when pushing for a quick including of a patch into the official POV-Ray,
> these people also want to leave at least some of the work of fixing the
> bugs to the POV-Team.
> 
(1) One does not need to integrate patches quickly into povray. 
    But one could at least make it easier for people to write their 
    patches. 
(2) If some people do not want to take responsibility for their code 
    once it is included in povray, than that is sad. A solution has 
    to be found which does not hurt those people who behave "correctly". 

> I have no problem with someone turning to other interests, but I have a
> problem if they do so only after they made the community curious about
> their work.
> 
If one threatens to de-integrate the patch, there will probably be 
somebody who finds it useful and takes over the responsivbility. 
If tere is not, there seems to be no interest at all and one can live 
without that functionality. 
I don't think this is the best solution but a fallback...

> cases.  So, if you consider the POV-Team being careful about adding new
> features "to hinder those people who want to work", fine, I call it
> prevention of wasting even more of our free time on something simply
> nobody else wanted to waste their free time doing.
> 
I was aware of these arguments before. 
The most basic idea against what I called "hindering" is to 
make available devel code (or at least beta versions) to those who 
want to "work". 

> In conclusion, contribute fixes for the real bugs that concern users, or
> quit complaining.
> 
Why not give people who want to do that the current code?

(I am not saying here that you send me the code and then I fix all the 
bugs -- just to be sure.) 

It's just that I learned to never fix bugs in old versions. I tracked 
down other bugs for other projects and the correct behaviour always was 
use the current development code and not a one-year-old code base. 

If I am the only non-team member thinking so, them this can be 
considered irrelevant by the team. But most people doing code review 
or open source development will probably consent. 

But probably nobody will read these lines because the posting is too long.

Wolfgang

Post a reply to this message